feat: add PS/2 keyboard interrupt driver - #2532
Conversation
7c21b3f to
5d35a06
Compare
There was a problem hiding this comment.
Benchmark Results
Details
| Benchmark | Current: a0b942a | Previous: 2e23902 | Performance Ratio |
|---|---|---|---|
| startup_benchmark Build Time | 81.02 s |
80.34 s |
1.01 ❗ |
| startup_benchmark File Size | 0.79 MB |
0.80 MB |
1.00 ❗ |
| Startup Time - 1 core | 0.76 s (±0.03 s) |
0.75 s (±0.02 s) |
1.02 |
| Startup Time - 2 cores | 0.76 s (±0.02 s) |
0.74 s (±0.02 s) |
1.03 |
| Startup Time - 4 cores | 0.77 s (±0.02 s) |
0.74 s (±0.02 s) |
1.03 |
| multithreaded_benchmark Build Time | 81.98 s |
82.11 s |
1.00 ❗ |
| multithreaded_benchmark File Size | 0.90 MB |
0.86 MB |
1.05 ❗ |
| Multithreaded Pi Efficiency - 2 Threads | 88.45 % (±4.80 %) |
85.89 % (±6.61 %) |
1.03 |
| Multithreaded Pi Efficiency - 4 Threads | 43.72 % (±2.98 %) |
43.43 % (±2.56 %) |
1.01 |
| Multithreaded Pi Efficiency - 8 Threads | 25.79 % (±1.54 %) |
25.76 % (±1.53 %) |
1.00 |
| micro_benchmarks Build Time | 79.44 s |
80.40 s |
0.99 ❗ |
| micro_benchmarks File Size | 0.90 MB |
0.86 MB |
1.05 ❗ |
| Scheduling time - 1 thread | 64.27 ticks (±2.76 ticks) |
62.65 ticks (±4.06 ticks) |
1.03 |
| Scheduling time - 2 threads | 35.61 ticks (±4.38 ticks) |
34.08 ticks (±4.10 ticks) |
1.04 |
| Micro - Time for syscall (getpid) | 4.19 ticks (±0.65 ticks) |
3.45 ticks (±0.58 ticks) |
1.21 |
| Memcpy speed - (built_in) block size 4096 | 82610.25 MByte/s (±57315.84 MByte/s) |
82448.38 MByte/s (±56997.13 MByte/s) |
1.00 |
| Memcpy speed - (built_in) block size 1048576 | 30568.37 MByte/s (±24651.80 MByte/s) |
30585.98 MByte/s (±24707.84 MByte/s) |
1.00 |
| Memcpy speed - (built_in) block size 16777216 | 29191.01 MByte/s (±24008.27 MByte/s) |
26340.06 MByte/s (±21720.96 MByte/s) |
1.11 |
| Memset speed - (built_in) block size 4096 | 82141.70 MByte/s (±57018.57 MByte/s) |
82292.76 MByte/s (±56891.50 MByte/s) |
1.00 |
| Memset speed - (built_in) block size 1048576 | 31289.18 MByte/s (±25071.68 MByte/s) |
31323.85 MByte/s (±25145.86 MByte/s) |
1.00 |
| Memset speed - (built_in) block size 16777216 | 29950.62 MByte/s (±24447.47 MByte/s) |
27104.68 MByte/s (±22209.94 MByte/s) |
1.10 |
| Memcpy speed - (rust) block size 4096 | 75192.59 MByte/s (±52284.95 MByte/s) |
74097.96 MByte/s (±51811.44 MByte/s) |
1.01 |
| Memcpy speed - (rust) block size 1048576 | 30501.53 MByte/s (±24583.52 MByte/s) |
30361.60 MByte/s (±24602.37 MByte/s) |
1.00 |
| Memcpy speed - (rust) block size 16777216 | 29470.74 MByte/s (±24245.88 MByte/s) |
27625.34 MByte/s (±22806.88 MByte/s) |
1.07 |
| Memset speed - (rust) block size 4096 | 75672.24 MByte/s (±52631.14 MByte/s) |
74373.47 MByte/s (±51976.48 MByte/s) |
1.02 |
| Memset speed - (rust) block size 1048576 | 31240.19 MByte/s (±25016.59 MByte/s) |
31110.89 MByte/s (±25033.24 MByte/s) |
1.00 |
| Memset speed - (rust) block size 16777216 | 30233.33 MByte/s (±24682.98 MByte/s) |
28386.93 MByte/s (±23265.03 MByte/s) |
1.07 |
| alloc_benchmarks Build Time | 77.24 s |
74.76 s |
1.03 ❗ |
| alloc_benchmarks File Size | 0.87 MB |
0.87 MB |
1.00 ❗ |
| Allocations - Allocation success | 91.31 % |
91.31 % |
1 |
| Allocations - Deallocation success | 100.00 % |
100.00 % |
1 |
| Allocations - Pre-fail Allocations | 61.44 % |
61.44 % |
1 |
| Allocations - Average Allocation time | 4406.77 Ticks (±81.81 Ticks) |
5860.58 Ticks (±98.43 Ticks) |
0.75 ❗ |
| Allocations - Average Allocation time (no fail) | 5229.00 Ticks (±81.84 Ticks) |
6554.81 Ticks (±92.86 Ticks) |
0.80 ❗ |
| Allocations - Average Deallocation time | 1241.78 Ticks (±107.09 Ticks) |
1805.01 Ticks (±250.35 Ticks) |
0.69 ❗ |
| mutex_benchmark Build Time | 77.72 s |
79.82 s |
0.97 ❗ |
| mutex_benchmark File Size | 0.90 MB |
0.86 MB |
1.05 ❗ |
| Mutex Stress Test Average Time per Iteration - 1 Threads | 12.20 ns (±0.45 ns) |
12.10 ns (±0.41 ns) |
1.01 |
| Mutex Stress Test Average Time per Iteration - 2 Threads | 41.48 ns (±2.08 ns) |
40.26 ns (±1.68 ns) |
1.03 |
This comment was automatically generated by workflow using github-action-benchmark.
2c424d5 to
f6c859b
Compare
mkroening
left a comment
There was a problem hiding this comment.
Thanks for the PR! :)
I was wondering why implement drivers for legacy devices instead of USB keyboards (xhci, usb-oxide, embassy-usb). I guess it is because of simplicity.
It would be great to discuss the high-level application-facing API, since that is the hardest to change once merged.
| ## Enables the PS/2 keyboard driver. | ||
| ## | ||
| ## This is only useful on PCs (x86-64). | ||
| keyboard = [] |
There was a problem hiding this comment.
Could you rename this to pc-keyboard? Also, please make sure that the docs don't imply that this is needed for keyboard support in general. Serial-based keyboard support is separate from this. Similar to the framebuffer, please also put a disclaimer that this does not make the kernel use the driver and instead exposes an API for applications that need to be ported.
| } | ||
|
|
||
| pub(crate) fn install_handlers(handlers: InterruptHandlerMap) { | ||
| pub(crate) fn install_handlers(#[allow(unused_mut)] mut handlers: InterruptHandlerMap) { |
There was a problem hiding this comment.
Please move the allow to the function level instead of having it inline like this.
| data_port.write(config); | ||
| cmd_port.write(PS2_CMD_ENABLE_KEYBOARD); | ||
| } | ||
| fn keyboard_handler() { |
There was a problem hiding this comment.
Please move the handler to the top level outside of this function.
| while (cmd_port.read() & PS2_BUFFER_FULL) != 0 { | ||
| let _ = data_port.read(); | ||
| } |
There was a problem hiding this comment.
Why do we discard the device buffer instead of filling our read buffer?
There was a problem hiding this comment.
At the start there might be garbage data in the output buffer, that can get stuck if we don't clear it.
https://wiki.osdev.org/I8042_PS/2_Controller#Step_4:_Flush_The_Output_Buffer
| let mut cmd_port = Port::<u8>::new(PS2_CMD_PORT); | ||
| let mut data_port = Port::<u8>::new(PS2_DATA_PORT); |
There was a problem hiding this comment.
Do you think an abstraction similar to the proposal for BGA would make sense?
struct Ps2;
impl Ps2 {
fn read_data() -> u8;
fn write_data(data: u8);
fn status() -> u8;
fn command(command: u8);
}| /// Pops a scancode from the keyboard buffer, returning None if the buffer is empty. | ||
| pub fn pop_scancode() -> Option<u8> { |
There was a problem hiding this comment.
A scancode can never be zero, right? Returning Option<NonZero<u8>> would be preferable in that case.
| #[cfg(all(target_arch = "x86_64", feature = "keyboard"))] | ||
| #[hermit_macro::system] | ||
| #[unsafe(no_mangle)] | ||
| pub extern "C" fn sys_read_keyboard() -> u8 { | ||
| crate::kernel::keyboard::pop_scancode().unwrap_or(0) | ||
| } |
There was a problem hiding this comment.
I am not too sure about this API. Is the application supposed to busy loop on this and retrieve one event at a time?
What about doing something similar to Linux's event device (evdev) interface (Linux docs)? Reading from /dev/input/event0 would then fill a user buffer with input events and blocks if no events are there unless opened with O_NONBLOCK.
There was a problem hiding this comment.
Since we don't use a filesystem like Linux I would propose something like this:
pub extern "C" fn sys_read_keyboard(buffer: *mut u8 ,size: usize, nonblock: bool) -> isize
(Should I also rename the systemcall to sys_read_pc_keyboard?)
This would be pretty flexible, we can throw standard errorcodes or return the buffersize in bytes like this.
We can then use a semaphore to block the thread until there are scancodes in the vecdeque.
f6c859b to
0a1c568
Compare
0a1c568 to
a7180a7
Compare
a7180a7 to
153302f
Compare
| let scancode = Ps2::read_data(); | ||
| let mut buffer = KEYBOARD_BUFFER.lock(); | ||
|
|
||
| if buffer.len() >= BUFFER_SIZE { | ||
| buffer.pop_front(); | ||
| } | ||
| buffer.push_back(scancode); |
There was a problem hiding this comment.
I wonder if retaining the keys in the queue is how this is handled best. I'm thinking that maybe adding a timestamp to each key event and discarding it after x seconds is a correct approach. But maybe I'm prematurely optimizing this. It would be interesting to know how other systems are handling this.
3473d4f to
2913b39
Compare
4e33054 to
166f396
Compare
Co-authored-by: Jonathan <github@jonathanklimt.de>
This feature adds support for the PS2 legacy keyboard in Qemu x86_64.
Currently it does:
The systemcall returns 0 if the keyboard feature is disabled.
I have only tested this feature with C programs on a Mac using Qemu.